home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄23⁄90 / 0733-More On UnloadAllSeg-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-23  |  3.0 KB  |  78 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    8143421                         22-Feb-90        01:05PST
  4.  
  5. From:   CDA0004                         VAR Shana Corp, Don Murphy,IVR
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    More On UnloadAllSegs
  10.  
  11. Attn: MacApp Technical
  12. SentBy: Wayne Malkin
  13. Date   2/21/90
  14. Subject    More On UnloadAllSegs
  15. From   Wayne Malkin
  16. To MacApp Technical
  17.  
  18.  Memo         Subject:More On UnloadAllSegs
  19.  
  20. Some time ago, Larry said he didn't think UnloadAllSegs and LoadSeg introduced
  21. much overhead, although he hadn't tried it.
  22.  
  23. Well, I tried it and it does. Actually, it only makes a big difference when
  24. the user is doing something like typing, and things keep getting unloaded and
  25. loaded between each character.
  26.  
  27. On that note, here are some additional ideas for UnloadAllSegs:
  28.  
  29. • Don't unload if you don't have to
  30.  
  31. I had a test in the LoadSeg patch to see if the segment is currently unloaded,
  32. and if the total of currently loaded code plus this one exceeds a specific
  33. limit. If so, then call UnloadAllSegs, which is careful to only unload things
  34. not in the current call chain.
  35.  
  36. This works well, but I found that in a certain case where the user was tabbing
  37. from field to field on a form, slightly more than the above code limit was
  38. touched (and therefore loaded). I had the limit set at 220k, which was more
  39. than adequate, as the longest calling chain is about 140k. The tabbing code,
  40. however, called a total of 250k of code at some point. Therefore UnloadAllSegs
  41. was being called at least once during each tab.
  42.  
  43. The traditional approach of re-segmenting may have worked in this case, but we
  44. already have 110 segments, and things are getting out of hand. Isn't there a
  45. limit of 255 code segments or something? Also, if you are running out of jump
  46. table space, splitting segments will not be a good idea.
  47.  
  48. I found that this slowed things down dramatically, from the user's point of
  49. view. If the user held down the TAB key, it went from field to field in slow
  50. motion. If I broke into MacsBug and upped the limit to 250k, tabbing
  51. performance improved by about a factor of 4.
  52.  
  53. My solution was to define another limit which represents the minimum available
  54. user memory. I set this to 32k, which, in addition to the 32k low memory
  55. reserve already in place, leaves about 64k for emergency use.
  56.  
  57. The LoadSeg patch now checks if user memory is less than the 32k limit, and if
  58. not, doesn't unload. Things now work smoothly as long as memory is plentiful,
  59. and things start unloading all over the place as soon as memory gets tight.
  60. Works like a dream.
  61.  
  62. I also modified many of the memory allocation routines to retry after calling
  63. UnloadAllSegs if a memory request fails. This may be needed if a request is
  64. made for memory that should be there but isn't because too much code is
  65. locked.
  66.  
  67. • Writelns
  68.  
  69. I also found that the writeln unit needs to be made resident, since
  70. WWDriver.c.o doesn't do nice stack frames, and WWSeg gets the rug pulled out
  71. from under it on a regular basis.
  72.  
  73. That is the only problem I have had so far.
  74.  
  75. -- Wayne Malkin
  76.  
  77.  
  78.